An OpenID is a shared identity service, which allows Internet users to log on to many different web sites using a single digital identity, eliminating the need for a different user name and password for each site. When using OpenID-enabled sites, users do not need to remember traditional authentication credentials such as username and password that are usually different for each web site. Instead, users only need to be registered with an OpenID “Identity Provider” (IdP), from which user is assigned a unique identity in the form of HTTP URL. Using only the identity, user can sign in every OpenID-enabled site.
There are three terms among others defined in OpenID standard that are particularly relevant to the present invention:
Identifier: A unique HTTP URL assigned to a user by IdP, for example, http://example.com/Smith.
Consumer: An Internet service provider that allows a user to use an OpenID Identifier to sign in its web site and requires a proof that the user owns the claimed Identifier.
IdP: Identity Provider that assigns an Identifier to a user and authenticates a user on behalf of the Consumers.
FIG. 1A shows a high-level relationship between entities in OpenID architecture. A user 101 claims her Identifier to a sign in Consumer (=Internet service provider) 103. The Consumer 103 delegate authentication of the user 101 with the corresponding IdP 102, by using the received Identifier. The IdP 102 authenticates the user 101 on behalf of the Consumer 103. By doing so, as similar to Liberty Alliance, single sign-on is possible as Consumer 103 accepts OpenID Identifiers and delegate actual user authentication with IdP 102.
FIG. 1B illustrates a high-level flow of OpenID authentication. Please note that it is assumed that there is a trust relationship between Consumer 103 and IdP 102 in that they agree on a shared secret so that exchanged messages between them through a user are verified in a secure way.
In step S101, a user of web browser connects to a Consumer web site and enters her OpenID Identifier, for example, “http://example.com/Smith” in an input form.
In step S102, the Consumer 103 fetches a web page designated by the URL according to the OpenID Identifier. The web page contains a link reference tagged by “openid.server” that points to the corresponding IdP endpoint URL. For instance, <link rel=“openid.server” href=” http://example.com/openid-auth”/> is provided in an HTML <header> of the fetched web page where “http://example.com/openid-auth” represents an IdP endpoint URL.
In step S103, the Consumer 103 redirects the browser to that IdP endpoint URL. In step S104, some authentication session starts between the IdP 102 and the browser in a user terminal used by the user 101, for instance the IdP 102 sends a password input form to the browser. Note that OpenID standard does not specify how the user 101 is authenticated by an IdP 102 but an IdP 102 can choose a preferred authentication method.
In step S105, after successful user authentication, the browser is again redirected to the original Consumer 103. The redirecting request contains an authentication result signed by the IdP 102. The Consumer 103 verifies this to know the user has been successfully authenticated.
OpenID is increasingly gaining adoption among large sites, with organizations acting as OpenID IdPs.
It will become a common practice for telecom operators to offer an OpenID IdP service to their subscribers so that their subscribers can obtain an additional user identity, an OpenID Identifier, which is usable in the Internet domain besides traditional telecom identities like MSISDN (Mobile Subscriber ISDN Number) and IMPU (IMS Public User Identity).
Comparing to existing OpenID IdP services provided by Internet service providers that rely on password-based user authentication toward those IdPs, one possible advantage of an OpenID IdP operated by telecom operators is more secure user authentication mechanism based on a SIM credential, for instance, by means of GBA (Generic Bootstrap Architecture) which is defined in 3GPP TS 33.22-V7.3.0 (2006-03), “Generic Authentication Architecture; Generic Bootstrap Architecture”. In this case, the telecom operator has a table to associate subscriber's authentication identity such as IMS Private Identity (IMPI) associated with an OpenID Identifier, which may be stored in a Home Subscriber Server (HSS).
FIG. 1C depicts a mechanism in which a mobile handset 111 establishes a GBA-authenticated HTTP session 112 (by means of HTTP Digest and/or TLS as specified in 3GPP TS 24.109 V7.3.0 (2006-06), “Bootstrapping interface (Ub) and network application function interface (Ua), Protocol details”) when the mobile handset 111 is redirected to the IdP 102 by the Consumer 103. Since this GBA authentication 112 can be performed silently without any user interaction involved, the user does not need to even remember and enter a password corresponding to her OpenID Identifier given by the operator 102.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard for handling multimedia services and sessions in the packet domain (for details regarding the IMS, please refer to http://www.3gpp.org/ftp/Specs/html-info/22173.htm). Various communication terminals and devices (hereinafter referred to as IMS terminals) that conform to the IMS standard are now known. A typical example of an IMS terminal is a mobile phone with IMS functionality. A personal computer (PC), a personal digital assistant (PDA), or the like can also serve as IMS terminals if they are equipped with IMS functionality. IMS terminals can provide multimedia services by, for example, receiving video streaming from a video-streaming server over an IMS network.
According to International Publication No. WO 2006/045706 which discloses a multimedia gateway called a “Home IMS Gateway” (HIGA), enabling non-IMS terminals which do not have an IMS functionality such as a desktop PC and a laptop PC to access services via the IMS network. The HIGA is located in a private network, to which at least one user terminal is connected. HIGA can be implemented on a “Set Top Box” (STB), a “Residential Gateway” (RGw) or different home devices.
It is desired to provide a system in which a user of user terminal connected to the HIGA can sign-in an Internet service using an OpenID Identifier while actual user authentication toward the IdP (=IMS operator) is performed via GBA based on a HIGA's ISIM credential.